---title: "Transcrição da Prova Teórica 1 — Davi José do Nascimento" discente: "Davi José do Nascimento" matricula: "20243001685" arquivo_scanner: "Davi José do Nascimento_20243001685.pdf" prova: "Prova Teórica 1" semestre: "2026-2" data_aplicacao: "2026-10-19" status_presenca: "presente" total_paginas: 6 qualidade_leitura: legibilidade_global: "84%" classificacao: "Média Legibilidade (75-89%)" tipo_escrita: "Grafite / lápis cinza claro, cursiva arredondada" observacoes: "Prova escrita a lápis (grafite claro), o que reduz ligeiramente o contraste do scanner; cabeçalho assinado em caneta azul com campo de matrícula em branco. Todas as questões e diagramas foram respondidos." format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Transcrição da Prova Teórica 1 — Davi José do Nascimento ## Questão 1 — Projeto, Ciclo de Vida e Trade-offs (5,0 pts) — [Página 1] * **Legibilidade da Questão:** 86% ### 1.1 Projeto vs. Operação (Valor: 1,5) * **Resposta Manuscrita:** > "É um projeto. Após feito e devidamente configurado ele não requer mais um apoio constante durante seu tempo em uso, sendo assim um trabalho único com começo, meio e fim." * **Observações de Leitura (OCR):** Traço de grafite legível; identificou trabalho único e temporalidade (começo, meio e fim). ### 1.2 Alternativas de Trade-off no Triângulo de Ferro (Valor: 2,0) * **Resposta Manuscrita:** > "Diminuir a quantidade de matérias que o assistente é capaz de ajudar: diminui o escopo mas não aumenta custo ou tempo. > Aumentar o orçamento para tokens e modelos: aumenta o custo mas não diminui o escopo nem aumenta o tempo." * **Observações de Leitura (OCR):** Cursiva em grafite claro; duas alternativas perfeitamente mapeadas no Triângulo de Ferro. ### 1.3 Classificação do Ciclo de Vida (Valor: 1,5) * **Resposta Manuscrita:** > "A abordagem é ágil, de forma que a cada 2 semanas um 'mini projeto' é entregue, podendo ou não ser dependente e ter relação com o anterior." * **Observações de Leitura (OCR):** Termo "mini projeto" entre aspas no original. --- ## Questão 2 — Escopo, EAP e Backlog (5,0 pts) — [Página 2] * **Legibilidade da Questão:** 82% ### 2.1 EAP e Regra dos 100% (Valor: 1,5) * **Diagrama / Elemento Visual:** * Nível 1: `[Interface do chat]` * Nível 2: `[geração de domínio]`, `[criação da tela]`, `[integração com backend]` * **Resposta Manuscrita:** > "A EAP assegura que uma funcionalidade seja dividida ao menor nível possível, formando uma hierarquia de complexidade aonde uma entrega mais acima depende diretamente das menores abaixo." * **Observações de Leitura (OCR):** Diagrama desenhado a lápis dentro do retângulo pontilhado. ### 2.2 Detalhamento de Issues e Estimativa Relativa (Valor: 1,5) * **Resposta Manuscrita:** > * **Issue 1.1.1:** Geração de domínio | Descrição: "Criar o domínio aonde a interface do chat ficará hospedada." | Critério de aceitação: "Domínio online reservado e acessível." | Estimativa: "Tempo estimado: 3 horas." > * **Issue 1.1.2:** Criação da tela | Estimativa: "Tempo estimado: 40 horas." > * **Justificativa Relativa:** "A segunda issue tem muito mais complexidade e nuances, tendo um tempo maior." * **Observações de Leitura (OCR):** Apresentou as duas issues com códigos hierárquicos e justificativa relativa do esforço. ### 2.3 Milestones vs. Sprints e Contexto do Kanban (Valor: 2,0) * **Resposta Manuscrita:** > "Milestones não substituem Sprints. Em um projeto pode se ter milestones definidos para entregas e prazos grandes e sprints menores, tudo em conjunto. Kanban sem sprint pode ser adotado em projetos de fluxo contínuo em que não possuam dependências entre as issues, onde uma atrasada impediria de fazer outra." * **Observações de Leitura (OCR):** Texto límpido a lápis nas três linhas finais. --- ## Questão 3 — Qualidade, CoQ e Definição de Pronto (5,0 pts) — [Página 3] * **Legibilidade da Questão:** 85% ### 3.1 Definição de Pronto (DoD) e Testes de Segurança (Valor: 1,5) * **Resposta Manuscrita:** > "DoD se refere ao parâmetro universal para todas as funcionalidades feitas, uma issue só é marcada como feita quando cumpre o DoD. No exemplo sem o teste de segurança o chat não pode ser marcado como feito pois para quem averiguar o projeto vai supor que os testes foram feitos, se baseando no DoD, gerando uma confusão e provável dívida técnica." * **Observações de Leitura (OCR):** Grafia clara; menção expressa aos termos "DoD" e "dívida técnica". ### 3.2 Categorização de CoQ e Severidade (Valor: 1,5) * **Resposta Manuscrita:** > "a. Prevenção > b. Avaliação > c. Falha externa > d. Falha interna > O bug em produção (falha externa) tende a ser mais caro pois foi descoberto depois, gerando um efeito cascata grande para a resolução e causando perdas financeiras." * **Observações de Leitura (OCR):** Mapeamento 100% correto das 4 opções com justificativa de efeito cascata. ### 3.3 Heurística 1:10:100 e Limites em IA (Valor: 2,0) * **Resposta Manuscrita:** > "A regra do 1:10:100 diz que um problema descoberto no planejamento tem custo 1, pois ainda está no começo e não foi realmente feito nada comprometido, nos testes possui custo 10, pois apesar de ter perda de trabalho e necessidade de revisão ainda é apenas interno, e um erro descoberto em produção tem custo 100, pois além de demorado para corrigir ainda expõe o erro ao usuário final, podendo causar problemas financeiros, técnicos, de segurança entre outros. Por isso não podemos negar verificações em testes, pois é mais barato." * **Observações de Leitura (OCR):** Explicação detalhada da progressão de custos. --- ## Questão 4 — Riscos, Segurança de IA e Documentação (5,0 pts) — [Página 4] * **Legibilidade da Questão:** 84% ### 4.1 Risco vs. Problema e Matriz P×I (Valor: 1,5) * **Diagrama / Elemento Visual:** * Marcação circular (ponto preenchido) desenhada no quadrante inferior direito (Impacto Alto × Probabilidade Baixa). * **Resposta Manuscrita:** > "Era um risco que virou um problema. Quando era só uma possibilidade era um risco, após ter um impacto vira um problema. A probabilidade era baixa, pois com certas camadas de segurança e experiência um desenvolvedor não faria isso, mas o impacto é crítico." * **Observações de Leitura (OCR):** Marcação na matriz e texto totalmente coerentes. ### 4.2 Ações Imediatas e Ação Preventiva Permanente (Valor: 1,5) * **Resposta Manuscrita:** > * **Ações imediatas:** "Retirada da chave e arquivos que possam possuí-la. Mudança de chave para outra não exposta. Contabilidade do custo gerado pelo vazamento com possível redução do orçamento do projeto para compensar." > * **Ação preventiva:** "Verificação manual se arquivos como .env estão sendo commitados." * **Observações de Leitura (OCR):** Apresentou três ações imediatas (revogação, rotação e contabilidade do custo) e verificação de arquivos sensíveis. ### 4.3 Modelagem de Risco de IA e Artefato ADR (Valor: 2,0) * **Resposta Manuscrita:** > * **Risco de Entrada:** "Prompt injection: Causa: usuário enviar comandos/instruções no prompt, (Probabilidade) alta, (Impacto) alto, (mitigação) verificação de saída, (contingência) banimento da conta." > * **Risco de Saída:** "Alucinação pedagógica: Saída verificada e tratada antes de chegar ao usuário." > * **Artefato Recomendado:** "ADR é o documento feito para guardar escolhas de arquitetura e segurança." * **Observações de Leitura (OCR):** Modelagem completa com ADR justificado expressamente. --- ## Questão 5 — Comunicação, Stakeholders e Conflitos (5,0 pts) — [Páginas 5 e 6] * **Legibilidade da Questão:** 83% ### 5.1 Comunicação Síncrona vs. Assíncrona no GitLab (Valor: 1,5) — [Página 5] * **Resposta Manuscrita:** > "Comunicação Síncrona: É em tempo real e permite uma duração estendida, mais humana, mas pode atrasar o desenvolvimento. > Comunicação Assíncrona: Tempo maior de resposta, gera registros e histórico, menos humana mas consome menos tempo de desenvolvimento. > Uma boa prática é fazer o misto dos dois. Reuniões via call com registro das decisões tomadas sendo enviada para todos os interessados e com atualizações assíncronas menores entre elas." * **Observações de Leitura (OCR):** Boa distinção entre canais em tempo real e assíncronos. ### 5.2 Matriz Poder × Interesse e Estratégia de Comunicação (Valor: 1,5) — [Página 5] * **Diagrama / Elemento Visual:** * Quadrante *Manter satisfeito* (Alto Poder, Baixo Interesse): `(5)` [Coordenação] * Quadrante *Gerenciar de perto* (Alto Poder, Alto Interesse): `(2)` [Professor], `(3)` [Equipe de desenvolvimento] * Quadrante *Monitorar* (Baixo Poder, Baixo Interesse): `(4)` [Provedor LLM] * Quadrante *Manter informado* (Baixo Poder, Alto Interesse): `(1)` [Alunos] * **Resposta Manuscrita:** > "O professor e a coordenação são quem possui maior poder sobre o projeto, podendo encerrá-lo ou exigir mudanças. Para o professor o melhor é possuir um canal de comunicação direta, via chat com atualizações e conversas frequentes sobre o andamento do projeto e funcionalidades, como o Telegram e e-mail." * **Observações de Leitura (OCR):** Posicionamento dos 5 stakeholders na matriz 100% perfeito. ### 5.3 Modos de Conflito de Thomas-Kilmann (Valor: 2,0) — [Página 6] * **Resposta Manuscrita:** > "Como ambas opiniões são contrárias não é possível seguir com as duas, sendo assim a melhor forma é um meio termo, buscando agradar as duas partes. Um exemplo seria um chat curto e socrático que pudesse oferecer respostas maiores dependendo da dificuldade do usuário, assim mantendo o objetivo de ensinar e evitando um custo exagerado por usuário. Respostas puramente longas por si só teriam um custo maior e poderiam incentivar alucinações e fugas de contexto, ao passo que respostas curtas podem não ser o suficiente para alunos com mais dificuldade." * **Observações de Leitura (OCR):** Análise madura de conciliação / compromisso, fundamentada nos custos de tokens e limitações pedagógicas.